Hackers Underworld 2: Forbidden Knowledge/Hackers Underworld 2: Forbidden Knowledge.iso/VIRUS/VIRS

Text File | 1989-10-11 | 12KB | 224 lines

////////////////////////////////////////////////////////////////////////////
from Meridian Systems, Haslett (Lansing), Michigan
multi-line service
Dr. Gordon Williams sysop [phone]
                          [phone], etc., overflow

Meridian systems serves as the format for State Senator William Sederburg's
"Political Forum".  Dr. Williams and Dr. Ken Salzman host a Human Services
Forum.  Dr. Glenn Keeney of MSU's Computer Science department hosts discussion
of programming and provides downloads from "Computer Language" and "AI Expert"
magazines.

UPCO is a local computer user group that contracted BBS services in order to
support their club.  Message base 8 was opened for discussion of viruses.

Lawrence Kestenbaum served as a County Commissioner for several years before
moving on to grad school at Cornell.  He provided a copy of the Jerusalem B
virus.

Mike Marotta (:-) is a technical writer.  His works have appeared in magazines
for IBM and Data General users, Defense Computing, Plan & Print, etc.  He is
the author of a book on codes and ciphers.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Msg#:39943 *UPCO Discussion*
09-24-89 13:03:21
From: MIKE MAROTTA
  To: LAWRENCE KESTENBAUM (Rcvd)
Subj: JERUSALEM B
I spent the morning with Jerusalem B and these are my preliminary results.
        Naturally, I made backups, etc.  I even made a new DOS diskette to use.
I gathered to this diskette some utilities such as LW86 (displays assembler
mnemonics and their syntax), CALC (for hex arithmetic), LIST and BROWSE,
FSDEBUG and plain old DEBUG, etc.  I used the infected files to build a "dirty"
diskette with NU.EXE, COMP, and some of my own COM and EXE programs.  XDIR.EXE
was written in C by a friend of mine.  I wrote RED.COM, BLUE.COM and
PRTSCR.COM.  RED and BLUE are 32 bytes each and change the screen colors.
PRTSCR is 4 bytes and does a "print screen".
        I found that NU.EXE reaches a top limit of 155k bytes (started at
148K).  About 5 re-infections seems to be the limit.  COM files were infected
just once each.  Re-infection, growth in file size) did not occur.
        Here's what I see happening.  You run a dirty program.  It goes to
MEMORY and alters the image of COMMAND.COM.  When you run a clean program, it
gets infected.  When the date is Oct 13, 1989 and you run an EXE or a COM, the
file deletes itself.  Some of these (XDIR, e.g.) ran once on "Oct 13" but then
erased themselves on the second call.
        Here is what is NOT happening.  You run a dirty program and it infects
all COM and EXE files.  I ran NU.EXE time after time.  WHile NU got bigger,
nothing else did.
        If you run a clean program AFTER a dirty program has been run, the
clean program gets infected.
        Because PRTSCR.COM, etc., are so small, I'll know in a few spare time
hours, just what the viral code is.  (more later)


Msg#:39950 *UPCO Discussion*
09-25-89 01:05:45
From: MIKE MAROTTA
  To: LAWRENCE KESTENBAUM (Rcvd)
Subj: JERUSALEM B
(Jesuralem is also easy to type and it even contains JESU...)
*
        I spent a total of 8 hours with JB, drank a beer, passed out and here I
am 6 hours later.  Some details.  EXEs keep getting infected, at least some of
them can.  COMs get infected once.  I wrote a program to output the letter A.
As a COM file it grew once.   The program to output the letter Z, left as an
EXE grew until it crashed.  (CLean it took only 32 bytes.  Maybe the small
size, you see.)  Now, ATTRIB.EXE grows forever, but it starts at, what? 6K? I
got it up to 22K and still hoggin'.  The increment is 1808 bytes.
*
        I listed the disassembled code (hope that doesn't violate the implicit
contract I entered into when I took the diskette out of the sleeve) via
DIS86PC.  (Some work here...Data and Code being equal, DIS86PC had some
interesting opinions about how to "execute" the "program fragment" COMMAND.COM)
The virus opens with a JUMP, so I took it from that argument, byte 195 forward.
*
        I found the TSR function, a DATE function, lots of read and write
functions, a few interrrupt vectors and lots of calls to memory locations near
0000:0000 to 0000:001F.  (Oddly enough the DATE checks only for the YEAR 1987.
I have yet to find 0A 0D = 10 13 but we'll see what tomorrow brings.)
        You know that looks a lot like 0D 0A, the CR LF pair ...


Msg#:39952 *UPCO Discussion*
09-25-89 01:48:18
From: MIKE MAROTTA
  To: GORDON WILLIAMS (Rcvd)
Subj: VIRUS, CONT.
I just rebooted and set the date to January 13th.  (also a Friday) and the two
executables I ran deleted themselves.
*
The Jerusalem B virus looks for and sets the file attributes with function 43
of INT 21.

Msg#:39958 *UPCO Discussion*
09-25-89 18:58:45
From: MIKE MAROTTA
  To: LAWRENCE KESTENBAUM (Rcvd)
Subj: JERUSALEM B
(It's getting easier to type Jerusalem... Let's hope no one invents a
Massachusetts or Connecticut virus...Then there's Azerbaidzhan and don't forget
Armenia's important city, Ordzhonikidze  though perhaps virus wars would be
preferable to ethnic rioting...)
*
        I found where JB looks for date and day.  I'm  about 2/3 through now
and I must say, I have respect for the programmer.  Error trapping and
failsafes all over the place.  The guy knows how to save a byte, also.  If he
knew that the argument for a call is something, he moves the whole word into AX
instead of MOV AH,12 and MOV AL,34.  He likes to PUSH and POP.  This is the
"real programmer's" way.  Me, I just MOV in again what I wished I'd PUSHed.
The program checks for disk type, and of course, changes the ATTRIButes of the
file.  Lots of error trapping. And it's TSR.  Neat.
*
        Now the next phase is to write a counter-program.  One that looks in
these places for this and that code and if the code is there, then you change
it so it's harmless. I already wrote some of this.  I have a program called
FOXY that goes to COMMAND.COM on a floppy and changes the program with no
alteration in size or date.  After being acted upon by FOXY, COMMAND.COM boots
with a message: "I am alive and I have rights."
*
        By the way, the monstrous size of ATTRIB (now at 66K) indicates
Jerusalem B does NOT write to the "slack" area of a file.  That in itself is a
challenge.  You can't do all that error trapping in a 256 bytes. Also, the
reason that FOXY acts only on floppies (and B: at that!) is to avoid just such
hassles.  The program is 32 bytes long and only because I allowed dead space
between the code and the message. I could still tighten it up...  But that
would leave maybe  16 bytes for error trapping.

Msg#:40038 *UPCO Discussion*
10-01-89 09:33:31
From: MIKE MAROTTA
  To: VIRUS HUNTERS
Subj: JERUSALEM B, CONT.
I must be making progress, I now have more questions than answers....
.       sUMsDos is the virus identifier tag.  At least this string appears at
the head and tail.  Of course, we have seen that EXE files are always
re-infected, so this mechanism is not perfect.  Also, near the tail of the
virus is the string EDLIN.
        I looked at EDLIN and it has a lot of open space, most of it at the end
of the file.  In all, EDLIN has about 2500 bytes available.  The Jerusalem B
virus runs 1808 bytes.  (This is hardcoded into the virus in several places,
e.g., MOV CX,0710 before an INT 21 function call.)  I wonder if EDLIN.COM was
the first host, or perhaps the first intended host.
        The string COMMAND.COM also shows up.  However, infection of
COMMAND.COM doesn't go well.  Mine crashed when I tried to invoke another DOS
shell.
        It has been suggested that JB does NOT infect COMMAND.COM in order to
make it less detectable, especially asfter the discovery of the "40th
Anniversary Virus" which infected the command processor.
        I have expressed by admiration for the great attention given to detail
in JB, but now I'm not so sure it is all necessary.  Now that I have worked my
way 100% thru the disassembly, I find many block of